System and method for installing loadable software airplane parts (lsap) of a set of certified orchestrated procedures using a blockchain network

ABSTRACT

A computer-implemented blockchain system for distributing, updating and verifying the installation of software embedded in an aircraft and for creating a built-in blockchain record of distributing, updating and verifying activities as proofs, including: a first node to insert into the distributed ledger in a first block of the blockchain storing a service record that contains distributable software code for updating the software embedded in the aircraft, and that specifies rules prescribing activities for loading, installing and verifying the software; a second node programmed to access the distributed ledger to obtain the service record and to initiate loading and installing activity performed upon the software embedded in the aircraft and to insert into the distributed ledger a second block of the blockchain storing a service record of at least one loading, installing and verifying activity was performed; and a third node to access the distributed ledger to obtain the service record.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to Indian Provisional PatentApplication No. 201811022399, titled “SYSTEM AND METHOD FOR INSTALLINGLOADABLE SOFTWARE AIRPLANE PARTS (LSAP) OF A SET OF ORCHESTRATEDACTIVITIES CERTIFIED BY A BLOCKCHAIN NETWORK” that was filed on 14 Jun.2018.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally toloadable software airplane parts, and more particularly, embodiments ofthe subject matter relate to a system and method for configuring ablockchain network for use with distributing, installing, updating, andvalidating software updates of aviation software components on anaircraft.

BACKGROUND

Aircrafts are increasingly getting more connected to ground controllersand this may result more often in problems from LSAP installations usedin aircraft connected systems. Despite the installing of the enhancedconnected technologies, receiving automated software updates toaircrafts has not progressed sufficiently fast enough when compared withother counterpart platforms. For example, software updates are installedat faster rates in mobile phones in general when compared with aircraftsystems. Hence, achieving a more robust solution for automated softwareupdates in aircrafts would lower ongoing financial and accountingburdens in the aviation industry by enabling better integrity of thesoftware systems on aircraft, reducing glitches in software systems ofaircraft and allowing for an overall better flight performance.

The current solutions for automated software updates found in theconsumer electronics industry for advanced robust remote softwareloading often prove to be inadequate solution for use in aircrafts dueto various impediments systematic to the aerospace and defenseindustries. That is, both the aviation and aerospace industries arecharacterized by complex decentralized workflows which is distributedamong multiple organizations and stringent regulatory requirements oftendue to the industry safety requirements. These characteristics can poseimpediments and are often seen as a major challenge for realizing afully/semi-automated loading of software parts or modules in an aircraftsystem; despite the fact that such aircraft systems are alreadyconnected to the ground or cloud based networks which can easily serveas the backbone for enabling such software updates. The result is thatthe current LSAP loading processes suffer from higher latency timeswhich are time consuming as well as labor intensive when performingsoftware updates.

Accordingly, it is desirable for improving both the performance androbustness of the LSAP loading process by using a fully/semi-automatedset of certified activities for installing, updating, and validatingsoftware updates in an aircraft by use of a blockchain network.Furthermore, other desirable features and characteristics will becomeapparent from the subsequent detailed description and the appendedclaims, taken in conjunction with the accompanying drawings and theforegoing technical field and background.

BRIEF SUMMARY

Some embodiments of the present disclosure provide a system and methodfor orchestrating activities of multiple entities or organizations togenerate record of the activities performed for distributing,installing, updating and validating of LSAP software updates in anaircraft system.

In one embodiment, a computer-implemented blockchain based system forremotely distributing, updating and verifying the installation ofloadable software in an aircraft and for creating a built-in trustedrecord of distributing, updating and verifying activities as proof isprovided. The system includes: a data communication network having aplurality of nodes each node implemented by at least one computerprogrammed to cooperatively maintain a copy of a distributed ledgerorganized as a blockchain of linked encrypted record-storing blocks; atleast a first one of said plurality of nodes being programmed to insertinto the distributed ledger in a first block of the blockchain storing,as an automated workflow, a service record that contains (a)distributable software code for updating the software embedded in theaircraft, and that specifies (b) rules prescribing activities forloading and installing the software embedded in the aircraft, and (c)rules for verifying that the updated software conforms to a predefinedor prescribed standard; at least a second one of said plurality of nodesbeing programmed (a) to access the distributed ledger to obtain theservice record and to initiate at least one distributing, loading andinstalling activity performed upon the software embedded in the aircraftto effect updating thereof using the distributable software code and (b)to insert into the distributed ledger a second block of the blockchainstoring a record of a fact that the at least one loading and installingactivity was performed and the success thereof; at least a third one ofsaid plurality of nodes being programmed (a) to access the distributedledger to obtain the service record and to apply at least one verifyingrule to test whether the updated software conforms to the predefined orprescribed standard and (b) to insert into the distributed ledger athird block of the blockchain storing a service record of the fact thatthe at least one verifying rule was applied and an outcome thereof; andat least the first, second and third ones of said plurality of nodesbeing programmed to collectively share immutable copies of the first,second and third blocks of the blockchain thereby ensuring that thedistributed ledger is immutable.

In various embodiments, the computer-implemented blockchain systemprovides: the first, second and third nodes together control theinstallation of the software embedded in the aircraft in a manner toensure no inadvertent activities are performed. The installation by thefirst, second and third nodes is controlled by a trusted workflowcontract executed by an entity associated with at least one of thefirst, second or third nodes. The trusted workflow contract comprises: aset of rules for updating the software to: assess applicability of thesoftware update for a particular aircraft; validate whether the softwareupdate is correctly loaded into the particular aircraft; and verifywhether at a post load completion of the software update, the softwarecomplies with an approved software update loading procedure. The nodesare a plurality of entities comprising: a loadable software airplanepart (LSAP) supplier, a carrier, a regulator, owner, and an aircraft.The computer-implemented blockchain system further includes: at leastone activity of a plurality of activities stored in the record of thesecond block of actions performed by a plurality of clients in apipeline processing defined by the approved software update loadingprocedure and associated with the plurality of nodes wherein theplurality of activities performed comprise one or more steps of:publishing a service bulletin, monitoring a fleet of aircrafts, creatinga work order, monitoring a software update loading process, selectingand uploading a software update, verifying a software update, checking acompliance and viewing a logbook. The plurality of clients include oneor more clients of: software part supplier, maintenance manager,maintenance technician, inspector, and a pilot. The one or more clientsassociated with the activities are remotely located from the entitiesassociated with the nodes.

In another embodiment, a method for remotely updating and verifyingsoftware updates in an aircraft and for creating a built-in blockchainrecord of updating and verifying activities as proofs is provided. Themethod includes: configuring a data communication network having aplurality of nodes each node implemented by at least one computerprogrammed to cooperatively maintain a copy of a distributed ledgerorganized as a blockchain of linked encrypted record-storing blocks;programming at least a first one of said plurality of nodes to insertinto the distributed ledger in a first block of the blockchain storing,as an automated workflow, a service record that contains (a)distributable software code for updating the software embedded in thevehicle, and that specifies (b) rules prescribing activities for loadingand installing the software embedded in the aircraft, and (c) rules forverifying that the updated software conforms to a predefined orprescribed standard; programming at least a second one of said pluralityof nodes (a) to access the distributed ledger to obtain the servicerecord and to initiate at least one loading and installing activityperformed upon the software embedded in the aircraft to effect updatingthereof using the distributable software code and (b) to insert into thedistributed ledger a second block of the blockchain storing a servicerecord of the fact that the at least one loading and installing activitywas performed and the success thereof; programming at least a third oneof said plurality of nodes (a) to access the distributed ledger toobtain the service record and to apply at least one verifying rule totest whether the updated software conforms to the predefined orprescribed standard and (b) to insert into the distributed ledger athird block of the blockchain storing a service record of a fact thatthe at least one verifying rule was applied and an outcome thereof; andprogramming at least the first, second and third ones of said pluralityto collectively share immutable copies of the first, second and thirdblocks of the blockchain thereby ensuring that the distributed ledger isimmutable.

In various embodiments, the method includes: the first, second and thirdnodes together control the installation of the software embedded in theaircraft in a manner to ensure no inadvertent activities are performed.The installation by the first, second and third nodes is controlled by atrusted workflow contract executed by an entity associated with at leastone of the first, second or third nodes. The trusted workflow contractincludes: a set of rules for updating the software for: assessingapplicability of the software update for a particular aircraft;validating whether the software update is correctly loaded into theparticular aircraft; and verifying whether at a post load completion ofthe software update, the software complies with an approved softwareupdate loading procedure. The nodes are a plurality of entitiesincluding: a loadable software airplane part (LSAP) supplier, a carrier,a regulator, owner, and an aircraft. The method further includes:storing at least one activity of a plurality of activities in the secondblock service record of actions performed by a plurality of clients in apipeline processing defined by the approved software update loadingprocedure and associated with the plurality of nodes wherein theplurality of activities performed include one or more steps of:publishing a service bulletin, monitoring a fleet of aircrafts, creatinga work order, monitoring a software update loading process, selectingand uploading a software update, verifying a software update, checking acompliance and viewing a logbook. The plurality of clients include oneor more clients of: software part supplier, maintenance manager,maintenance technician, inspector, and a pilot. The one or more clientsassociated with the activities are remotely located from the entitiesassociated with the nodes.

In yet another embodiment, a method for executing instructions on anon-transitory computer-readable medium by at least one processor isprovided. The method includes: configuring a data communication networkhaving a plurality of nodes each node implemented by the at least oneprocessor programmed to cooperatively maintain a copy of a distributedledger organized as a blockchain of linked encrypted record-storingblocks; programming at least a first one processor of said plurality ofnodes to insert into the distributed ledger in a first block of theblockchain storing, as an automated workflow, a service record thatcontains (a) distributable software code for updating the softwareembedded in an aircraft, and that specifies (b) rules prescribingactivities for loading and installing the software embedded in theaircraft, and (c) rules for verifying that the updated software conformsto a predefined or prescribed standard; programming at least a secondone processor of said plurality of nodes (a) to access the distributedledger to obtain the service record and to initiate at least one loadingand installing activity performed upon the software embedded in theaircraft to effect updating thereof using the distributable softwarecode and (b) to insert into the distributed ledger a second block of theblockchain storing a service record of a fact that the at least oneloading and installing activity was performed and the success thereof;programming at least a third one processor of said plurality of nodes(a) to access the distributed ledger to obtain the service record and toapply at least one verifying rule to test whether the updated softwareconforms to the predefined or prescribed standard and (b) to insert intothe distributed ledger a third block of the blockchain storing a servicerecord of a fact that the at least one verifying rule was applied and anoutcome thereof; and programming at least the first, second and thirdone processors of said plurality of nodes to collectively shareimmutable copies of the first, second and third blocks of the blockchainthereby ensuring that the distributed ledger is immutable.

In various embodiments, the method includes: the first, second and thirdone processors of said plurality of nodes together control theinstallation of the software embedded in the aircraft in a manner toensure no inadvertent activities are performed wherein the installationis controlled by a trusted workflow contract executed by an entityassociated with at least one of the first, second or third nodes. Thetrusted workflow contract include: a set of rules for updating thesoftware for: assessing applicability of the software update for aparticular aircraft; validating whether the software update is correctlyloaded into the particular aircraft; and verifying whether at a postload completion of the software update, the software complies with anapproved software update loading procedure. The method further includes:storing at least one activity of a plurality of activities in the secondblock service record of actions performed by a plurality of clients in apipeline processing defined by the approved software update loadingprocedure and associated with the plurality of nodes wherein theplurality of activities performed include one or more steps of:publishing a service bulletin, monitoring a fleet of aircrafts, creatinga work order, monitoring a software update loading process, selectingand uploading a software update, verifying a software update, checking acompliance and viewing a logbook.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures.

FIG. 1 illustrates an exemplary LSAP loading diagram of variousorchestrating approved software loading procedure activities which maybe used in generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment;

FIG. 2 illustrates a LSAP loading network diagram of the orchestratingactivities of multiple organizations for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 3 illustrates a LSAP loading network with deployable trust-flowcontracts representing an organization which has one or more nodesconnected to end users interacting with the blockchain network via thenodes of the organization for generating data of the blockchain ledgerof the LSAP blockchain network in accordance with an embodiment;

FIGS. 4A and 4B illustrate a LSAP loading network with deployablecontract of the orchestrating activities of multiple organizations forgenerating data of the blockchain ledger of the LSAP blockchain networkin accordance with an embodiment;

FIG. 5 illustrates a LSAP loading network with a semi-automatedinstallation procedure of the orchestrating activities of multipleorganizations for generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment;

FIG. 6 illustrates a LSAP loading network with an automated installationprocedure of the orchestrating activities of multiple organizations forgenerating data of the blockchain ledger of the LSAP blockchain networkin accordance with an embodiment;

FIG. 7 illustrates a pipeline of distribution, installation andverification procedure of the orchestrating activities of multipleorganizations for generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment;

FIG. 8 illustrates an LSAP loading architecture diagram of the partiesand organizations orchestrating activities for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 9 illustrates a snapshot of an user interface of a service bulletinfor sending to the parties and organizations orchestrating activitiesfor generating data of the blockchain ledger of the LSAP blockchainnetwork in accordance with an embodiment;

FIG. 10 illustrates a snapshot of a published service bulletin forsending to the parties and organizations orchestrating activities forgenerating data of the blockchain ledger of the LSAP blockchain networkin accordance with an embodiment;

FIG. 11 illustrates a snapshot of an user interface of the servicebulletin applicability for sending to the parties and organizationsorchestrating activities for generating data of the blockchain ledger ofthe LSAP blockchain network in accordance with an embodiment;

FIG. 12 illustrates a snapshot of an user interface of the maintenancemanager for creating the work order for sending to the parties andorganizations of orchestrating activities for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 13 illustrates a snapshot of an user interface of the maintenancemanager for monitoring the load progress and for sending to the partiesand organizations orchestrating activities for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 14 illustrates a snapshot of an user interface of the maintenancetechnician for selecting and uploading the software part and, ininstances, for sending to the parties and organizations orchestratingactivities for a semi-automated workflow for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 15 illustrates a snapshot of an user interface of the maintenanceinspector for verifying the uploading of the software part and, ininstances, for sending to the parties and organizations orchestratingactivities for a semi-automated workflow for generating data of theblockchain ledger of the LSAP blockchain network in accordance with anembodiment;

FIG. 16 illustrates a snapshot of an user interface of the inspectorchecking compliance of the software part and, in instances, for sendingto the parties and organizations orchestrating activities for generatingdata of the blockchain ledger of the LSAP blockchain network inaccordance with an embodiment;

FIG. 17 illustrates a snapshot of an user interface of the pilot viewingthe log of the software part installed on the aircraft related to theorchestrated activities for generating data of the LSAP blockchainnetwork in accordance with an embodiment;

FIG. 18 is a network diagram of the blockchain ledger with thecommunication network aircraft related to the orchestrated activitiesfor generating data of the LSAP blockchain network in accordance with anembodiment; and

FIG. 19 is a functional block diagram of a computing device related tothe client for the orchestrated activities for generating data of theLSAP blockchain network in accordance with an embodiment.

DETAILED DESCRIPTION

The following detailed description is merely illustrative in nature andis not intended to limit the embodiments of the subject matter or theapplication and uses of such embodiments. As used herein, the word“exemplary” means “serving as an example, instance, or illustration.”Any implementation described herein as exemplary is not necessarily tobe construed as preferred or advantageous over other implementations.Furthermore, there is no intention to be bound by any expressed orimplied theory presented in the preceding technical field, background,brief summary or the following detailed description.

Loadable Software Airplane Parts (LSAP) is becoming an integral part ofaircraft software system configuration. LSAP along with the relevantHardware parts constitute the Loadable system whose functionality can bemodified or changed by just updating the loadable software parts. Themajor advantage of this is as follows: airline carriers, owners,maintenance technician and others given appropriate access to onboardaviation systems are able to modify the configuration of these systemswithout physically modifying or replacing hardware components. This inturn can significantly reduce the number of LRU (Line replaceable unit)spares to be maintained in inventory by a carrier, manufacturer, owneretc. which results in cost savings and greater efficiencies in fixingproblems and ease to carry out software changes and by reducing glitchesthat occur in complex systems. In addition, the software loading withinthe TAT (turnaround time) of the aircraft for the next flight isdecreased.

For an airline to operate and maintain an aircraft having these loadablesystems/software, in various exemplary examples, the following processesshould be implemented which is not always achievable. Initially, aprocurement of Loadable software parts and Loadable (LRU) is requiredwhich involves ordering loadable software Parts and relevant LRUs froman original equipment manufacturer (OEM) by listing out the softwareparts to be loaded into the LRU. Also needed are Software LibrariesManagement: airline operators require a well-established and maintainedsoftware library, for maintaining Loadable software parts spares andupdated software as a part requiring a software changes can happenwithout notice. Also needed, is a preload Loadable Software Parts intoLoadable LRU of the Aircraft: When a loadable LRU is replaced, theLoadable software certified for the Aircraft should be loaded into theincoming LRU. The operator can achieve this by requesting suppliers toperform the same or by performing in their own maintenance shops usingshop loading equipment. Finally, a conformance of Loadable SoftwareConfiguration with Authorized Aircraft Configuration: This requires theoperator maintain record of all the loadable software parts available inan Aircraft and its conformance with the approved Aircraftconfiguration. Such a process should also ensure that, all the changesundergone for loadable software parts arising out of the ServiceBulletin are documented and readily available for any regularityauthority inspections.

That said, the Airline Operator is the responsible entity forimplementing procedures to control updates and modifications to loadablesystems, occurring after the airplane has been delivered. The partnumbers of the software loaded into a loadable system are part of thetype certificate of the airplane. The operator must ensure that theconfiguration control documentation for each airplane reflects thecurrent configuration of loadable software parts, and that the loadablesoftware parts are certified for the airplane on which the updates areinstalled.

In various exemplary embodiments, the present disclosure describes amechanism for intelligent automated software to perform loading softwareairplane parts as sub-tasks as per established workflow contractualrules, automated generation of records and management, and a secureprocess to prevent inadvertent and unauthorized updates of LSAPs onsystems of the aircraft.

In various exemplary embodiments, the present disclosure describes aCertifiable Trusted Workflow Automation process and a process for aremote distribution, loading and installation of airplane softwareparts.

In various exemplary embodiments, the present disclosure describes: aprivate permissioned blockchain network, a set of configurable Networkrules within the blockchain network to enable a set of deployableworkflow contracts based on trusted elements like Service bulletins, aset of task transactions based on workflow contracts, which ensure thatthe secure loading of LSAPs from remote system takes place, and anautomated tamper proof record generation of sub task.

The Table 1.0 below describes various benefits in exemplary embodimentsdescribed by converting written instruments of service bulletins todigital documents to facilitate the necessary software upgrades inaircrafts described by the service bulletins as well to maintainintegrity with software updates when installed in the aircraft systems.

Problem Area Exemplary Embodiments Described Service Bulletin comes asdocuments which SB is encoded as the executable code(smart areassimilated by Operator change contract) in the BC network. Assessmentof management team. the applicability is automatically determined Assessapplicability and constraints for their by the network fleet. OnboardManual Software upgrades some Maintenance node takes care of securely ofwhich take long time (sometimes > 1 loading of LSAPs. The successfulhour). completion of this task is endorsed by the Authorized Maintainerscarry the software participating nodes in the network. parts to theaircraft. Download the Software as per the instructions in the servicebulletin. This is constrained by geographies and authorized maintainers.Onboard Manual Inspections which requires This step is not required.Endorsements by authorized/certified and independent the participatingnodes ensure the inspection. Authorized Maintainers verify ifverification. the software parts has been upgraded authorized for thespecified aircraft. This is constrained by geographies and authorizedmaintainers, where different laws applies. Maintaining consistent tamperproof Auto generated digital distributed ledger. Aircraft recordsupdates for the entire life Collaboration without compromising on cycleof the aircraft. Most commonly proprietary systems manual updates to thepaper records is used. Managing consistently the integrity of therecords without losing these for long durations is a problem.

FIG. 1 illustrates an exemplary LSAP loading diagram 100 of theorchestrating approved software loading procedure activities forgenerating data of the blockchain ledger of the LSAP blockchain networkin accordance with an embodiment.

The LSAP loading diagram 100 receives the original equipmentmanufacturer (OEM)/supplemental type certificate (STC) release servicebulletins that instigates the process of loading and installing theLSAPs at 110. The service bulletins include the following information:the aircraft and hardware applicability, the verification procedures toassure that the software were correctly loaded into an approved andcompatible target computers; any post load verification and/or testprocedures required to show compliance with the guidelines specified inthis section of the Certification Memorandum; the actions to be taken inthe event of an unsuccessful load (for example, to prohibit the dispatchof the aircraft); the reference to an approved loading procedure; themaintenance record entry procedures required to maintain configurationcontrol; and the reference to the Aircraft Flight Manual or OperationsManual of the aircraft, as appropriate.

Alternately, the OEM or Vendors may notify operators of the Softwareupgrades through one of several other instruments, aside from ServiceBulletins (SB), these notifications may come from instruments thatinclude engineering orders, service letters (SL), vendor notificationsand OEM specific communications. The air operator certificate(AOC)/Owner at 115 after the notification from the information of theservice bulletin, may order both the software and hardware part numbersthat stipulate which software update is to be loaded into the loadablesoftware parts and loadable hardware (LRU). At 120, the maintenanceoffice may assess the applicability for the SB for the air certificate(AC). Next, at 130 the aircraft log records the upgrade. Here,inadequate records have been a constant problem identified by FAAresulting in operators spending substantial money to keep the records upto date. Like any parts on the aircraft, records have to be maintainedfor LSAP installation to meet the stringent safety requirements imposedin the industry.

The records are needed to match the actual aircraft configuration andthere should be no discernable configuration discrepancies to ensure theoperator will get the necessary AC without obstacles. At 135, thecertified inspector(s) may verify the upgrade and sign the return toservice notice. In order to mitigate risk to network security of theonboard systems of the aircraft, the off-airport supportinginfrastructure and links in between must include wired and wirelessconnectivity to ensure no public or unauthorized access. This ensuresthat data security protection is sufficient to prevent access byunauthorized devices or personnel external to the aircraft.Additionally, the wired and wireless connected pipeline ensures thatsecurity threats specific to the certificate holder's operations areidentified and assessed, and that risk mitigation strategies areimplemented to ensure the continued airworthiness of the aircraft. Thatis, steps are taken to prevent inadvertent or malicious changes to theaircraft network, including those possibly caused by maintenanceactivity. Also, unauthorized access from sources onboard the aircraft isalso prevented by this wired and wireless connected architecture. Next,at 150, the pilot verifies the upgrade and confirms airworthiness.Finally, at 160 the FAA/OEM/AC frequently audit and quality check therecords to ensure that the aircraft meets the proper requirements.

FIG. 2 illustrates a LSAP distribution and loading network diagram 200of the orchestrating activities of multiple organizations for generatingdata of the blockchain ledger of the LSAP blockchain network inaccordance with an embodiment.

Each organization in the network will have one or more specific roles inthe network to receive the record data into the network, validating therecord data and generating data blocks of static data in the block chainledger. In instances, the stakeholders 235 may have rights to modify andgenerate the underlying roles and trusted work-flow contracts of theblockchain network. The aircraft system 250 from the aircraft maybroadcast a current configuration of the aircraft upon request from anynumber of parties having access to the network or a particular partywith limited access for a given maintenance task. The authorizedmaintainer 240 may as an example initiate a particular LSAP installationand when completed issue the return to service approval. After thereturn to service approval is issues, a regulator 220 may be givenrights to either approve or reject the transactions based on normalweightage calculations. Next, an aircraft operator 230, in instances ofa necessitated higher approval may then have to approve or reject thetransactions based on a highest weightage. In other words, a two-stepweightage is implemented, where at a lower weightage no aircraftoperator 230 input is required for approval or rejection and thedecision making is given to the regulator 220 who is likely an inspectoron the ground. In instances, an LSAP supplier 245 is allowed limitedrights to approve or reject a transaction related to the particular LSAPloaded. The STC/TC Owner 225 can deploy the SB as a smart contract inthe network and approve or reject the transactions. In various exemplaryembodiments, the LSAP distribution server 255 may distribute to otheraircrafts similar or duplicate software updates, LSAP loadingprocedures, and like information as well as corresponding approval data.In instance, the LSAP distribution server 255 may distribute suchinformation outside the blockchain network to various individuals andorganizations as needed. The record viewer 215 (Pilot, Airlines Office,Lease assessment, etc.), Stake holders 235 are associated with clientsand nodes who have proprietary approval in the network.

FIG. 3 illustrates a LSAP loading network with deployable trust-flowcontract 300 of the orchestrating activities of intra organizations forgenerating data of the blockchain ledger of the LSAP blockchain networkin accordance with an embodiment.

Each organization on the blockchain BC network may have a proprietarynetwork 320 linked to a respective participating node. For example, aninspector 321 with a mechanic 322 and enterprise resource planning (ERP)323 may form a proprietary network 320 for connecting via the LSAPnetwork 315 to the blockchain network 315. The logic endorse anytransaction by an organization can be aided by the linked proprietarysystem. For example, when a LSAP load request is received on thenetwork, the LSAP vendor organization may reject this request based onthe vendor LSAP systems input. In an exemplary embodiment, the reasonfor such a rejection may be that the maintenance manager has not yetpurchased the required LSAP license.

FIGS. 4A and 4B illustrate a LSAP loading network with deployabletrust-flow contract 400 of the orchestrating activities of multipleorganizations for generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment.

FIGS. 4A and 4B. Shows a work flow diagram 400 of configurable set ofnetwork rules implemented with deployable trusted workflow contracts.The workflow is contracted via agreements with the organizations of theblock chain network and derived from Service bulletins or equivalentinstruments. The smart contracts are defined and developed in compliancewith regulatory requirements. The smart contracts may contain varioussections of rules such as the following: rules to assess applicabilityof parts for aircraft and specific hardware; rules to verify whether thesoftware was correctly loaded into an approved and compatible targetcomputer, and rules for post load verification and/or test proceduresrequired to show compliance with the guidelines specified, for exampleby a certification memorandum or like reference. The references maycover an approved LSAP loading procedure used or described with anAircraft Flight Manual or Operations Manual of the aircraft, asappropriate for the particular maintenance.

The Task Transactions based on workflow contracts will ensure the secureloading of LSAPs from a remote system. The various sub-tasks for theautomated remote loading process are described in FIG. 4. The work flowdiagram 400 includes the list of tasks but it is contemplated that theparticular list of tasks can be changed, modified or omitted as neededand the particular list described here is merely an exemplary list oftasks for a particular block chain network configuration. The work flowdiagram 400 includes: a task 410 to request to install an LSAP; a task420 to ready the network for the LSAP installation; a task 430 toauthorize an LSAP loading; a task 440 to complete the installation; anda task 450 to create the block in the block chain network.

FIG. 5 illustrates a LSAP loading network with a semi-automatedinstallation procedure 500 of the orchestrating activities of multipleorganizations for generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment. The semi-automatedinstallation procedure 500 begins with the LSAP software parts installer510 publishing the service bulletin 512 for review and applicability aswell as notification to the maintenance manager 515. At 520, themaintenance manager creates the work order 525 for the LSAP moduleinstallation and a selected work procedure 528 is executed for themaintenance technician 530. The maintenance technician 530 needs totrigger the software installation 530 at the aircraft 540. The aircraft540 notifies the maintenance technician 530 of the status of theinstallation. At 555, a verification of the installation is determinedby the inspector 550 and at 560, a notification is sent that theinstallation is complete to the maintenance manager 520, the pilot 570and the inspector 550 views the report 565 generated by the maintenancetechnician 575 of the installation.

In various exemplary embodiments, the blockchain ledger (not shown) mayreceive records of the service bulletin, the installation procedure, theinstallation status and the reports by the maintenance technician whencompleted. That is, in the semi-automated installation procedure 500,software calls may be configured for sending various steps in theprocess for recordation in record blocks which make up the blockchainledger to retain a permanent record of all activities in thesemi-automated LSAP installation procedure of software module updates.

FIG. 6 illustrates a LSAP loading network with an automated installationprocedure 600 of the orchestrating activities of multiple organizationsfor generating data of the blockchain ledger of the LSAP blockchainnetwork in accordance with an embodiment. The automated installationprocedure 600 differs from the semi-automated procedure in that thetechnician no longer triggers the software installation procedure.Rather when the maintenance manager 615 creates the work order 617, theselected work procedures 619 are automatically executed. Onceautomatically triggered, the software modules or updates are installedon the aircraft 620 which in turn notifies the status of theinstallation at 622, verifies the installation at 624, and notifiescompletion of the installation at 626. The report 630 created by themaintenance technician 645 can be viewed by the inspector 637 and thepilot 635. That is, once the installation is complete at 626, the pilotknows to look for the report 630 by the maintenance technician 645 ofthe installation and the inspection by the inspector 637.

As similarly indicated in the semi-automated installation procedure 500above, in the automated installation procedure 600 in various exemplaryembodiments, the blockchain ledger (not shown) may receive records ofthe service bulletin, the installation procedure, the installationstatus and the reports by the maintenance technician when completed.That is, in like the semi-automated installation procedure 500, softwarecalls may be configured in the automated installation procedure 600 forsending various steps in the process for recordation in record blockswhich make up the blockchain ledger to retain a permanent record of allactivities in the automated LSAP installation procedure of softwaremodule updates as needed. However, in the automated installationprocedure 600 less recordation may be necessary as certain steps may beimplicitly assumed (depending on the programming and configuration ofthe procedure) because such steps are automated in the installationprocedure and therefore may not needed to be verified of completion andlikewise recorded in the blockchain ledger.

FIG. 7 illustrates a pipeline installation procedure 700 of theorchestrating activities of multiple organizations for generating dataof the blockchain ledger of the LSAP blockchain network in accordancewith an embodiment.

The pipeline installation procedure 700 which incorporates thesemi-automated installation procedure 500 of FIG. 5 and the automatedinstallation procedure 600 of FIG. 6. The pipeline installationprocedure 700 begins with software parts supplier 710 publishing theservice bulletin 715 which is received by the maintenance manager 730that monitors the fleet of aircrafts 720 and creates the work order 725for the particular aircraft. The service bulletin 715 and the work order725 may be sent to the blockchain ledger 705 for permanently storing.Next, the maintenance technician 730 monitors the progress 735, selectsthe software part 740, and verifies the software part 745 for the LSAPloading procedure. Routines may be configured in the pipeline forsending the data as well as the status to the blockchain ledger 705. Inaddition, for all the steps, meta data may also be recorded in therecords of the block of the blockchain ledger 705. Finally, theinspector 750 checks for compliance 755 and a log book is created 765which may be viewed by the pilot 760.

In various embodiments, records of the data may be stored in the blocksof the blockchain ledger including times, dates, verification,validation, and completion of the software module installations andupdates in each step of the pipeline installation procedure 700 forfuture review, searching and compliance data that the service bulletinshave been received, the appropriate aircrafts identified andinstallations of the software validated and properly completed.

FIG. 8 illustrates an LSAP loading architecture diagram 800 of theparties and organizations orchestrating activities for generating dataof the blockchain ledger of the LSAP blockchain network in accordancewith an embodiment. The LSAP loading architecture diagram 800 includes aset of nodes 805 for each organization or stakeholder that takes part inthe trusted workflow contracts of the blockchain network. The set ofnodes 805 may be configured as remote servers coupled to client devicesof the respective clients of the blockchain network. Each node may beassigned a set of rights for notification, searching and validating ofinput to the blockchain defined by the set of trusted workflowcontracts. The sets of nodes 805 includes a company node 807, anaircraft node 825, an Maintenance, Repair and Overhaul (MRO) node 820,an airline node 815 and a supplier node 810. In the distributed networkarchitecture, each node will have a duplicate set of records that areupdated at similar if not the same time as the other nodes allowing foreach of the respective parties to rely on the same information. The setof clients includes the network operator 830, the maintenance technician840, the software part supplier 835, the pilot 845, the maintenancemanager 850, and the inspector 855. Each client can be configured to beenabled for certain tasks aligned with the client role in the pipelineprocessing and given access to other data or proprietary decisions madecan be limited.

FIG. 9 illustrates a snapshot of an user interface 900 of a servicebulletin for sending to the parties and organizations orchestratingactivities for generating data of the blockchain ledger of the LSAPblockchain network in accordance with an embodiment.

The user interface 900 is configured to enable an user to browse via abrowse button 910 and select 920 a particular service bulletin forsending out to the aircraft fleet.

FIG. 10 illustrates a snapshot of a service bulletin 1000 for sending tothe parties and organizations orchestrating activities for generatingdata of the blockchain ledger of the LSAP blockchain network inaccordance with an embodiment.

The published service bulletin 1010 includes information for the LSAPloading of the aircraft identifying type, the software module and theverification procedure. In various exemplary embodiments, the publishedservice bulleting 1010 may be recorded in the blockchain ledgerincluding all metadata of the parties sending the service bulletin andreceiving parties.

FIG. 11 illustrates a snapshot of an user interface 1100 of the servicebulletin applicability for sending to the parties and organizationsorchestrating activities for generating data of the blockchain ledger ofthe LSAP blockchain network in accordance with an embodiment.

The user interface 1100 includes the current fleet size 1110 which isbeing monitored, the selected aircraft 1120, the details of the lastupdate 1130 and availability of new updates 1140 and configurations ofthe updates 1150. The software and actions for an update in the deviceconfiguration window 1152 described in a particular configuration thekind of available, status, verification and validation data that may besent to the blockchain ledger at 1160.

In an exemplary embodiment, a work order may be created at 1185, anddisplays of notifications of work order not created 1180, work ordercreated 1175, staged on loader 1170 and loaded successfully 1165 may bestored in the blockchain ledger and displayed to the inspector, pilot,maintenance technician etc. In addition, each of the parties ororganizations responsible for the creation of the trust-flow contractsmay have access to this type of information depending on the blockchainnetwork configuration.

FIG. 12 illustrates a snapshot of an user interface 1200 of themaintenance manager for creating the work order for sending to theparties and organizations of orchestrating activities for generatingdata of the blockchain ledger of the LSAP blockchain network inaccordance with an embodiment.

FIG. 12 shows the user interface 1200 for creating the work order wherean user may select 1210 an automated or semi-automated work flow. Inaddition, the user may load the schedule at 1215 and choose data, timeand hours. The digital maintainer 1220 enables the selection of themaintenance technician or responsible party assigned by the maintenancemanager.

FIG. 13 illustrates a snapshot of an user interface 1300 of themaintenance manager for monitoring the load progress and for sending tothe parties and organizations orchestrating activities for generatingdata of the blockchain ledger of the LSAP blockchain network inaccordance with an embodiment.

The user interface 1300 includes notification of loading the software1310 and the verification check 1340. The loading of the software 1310includes identification of a software part 1320 and notification of thecompleted loading 1330. The verification check 1340 includes theverifying at 1350 of the software part 1355 “in progress” where theverification is automated 1360. The tabs at the bottom of the userinterface 1300 allow of user selection of the check status 1365 andselection of the aircraft log 1370 indicating visually to the user thatthe loading and verification steps have been logged in the aircraft logfor the particular aircraft.

FIG. 14 illustrates a snapshot of an user interface 1400 of themaintenance technician for selecting and uploading the software partand, in instances, for sending to the parties and organizationsorchestrating activities for generating data of the blockchain ledger ofthe LSAP blockchain network in accordance with an embodiment.

The user interface 1400 includes notification of connected to aparticular aircraft 1405, the software part 1410 selected for uploading,and a “button” for user selection to execute the upload of the softwarepart.

FIG. 15 illustrates a snapshot of an user interface 1500 of themaintenance technician for verifying the uploading of the software partand, in instances, for sending to the parties and organizationsorchestrating activities for generating data of the blockchain ledger ofthe LSAP blockchain network in accordance with an embodiment.

The user interface 1500 indicates the software part 1500 and theverification check 1520 for review by the maintenance technician where adetermination can be made that the software has passed 1530 or notpassed 1540 the verification test. In instances, the verification may beautomated or manually applied 1550 by the technician.

FIG. 16 illustrates a snapshot of an user interface 1600 of theinspector checking compliance of the software part and, in instances,for sending to the parties and organizations orchestrating activitiesfor generating data of the blockchain ledger of the LSAP blockchainnetwork in accordance with an embodiment. The compliance status 1610 bythe inspector can be designated at 1620 either “true” or “false” for aparticular aircraft. The log 1625 of the aircraft can show whether thestatus check 1630 was initiated by the maintainer and approved by theinspector or the STC owner.

FIG. 17 illustrates a snapshot of an user interface 1700 of the pilotviewing the log of the software part installed on the aircraft relatedto the orchestrated activities for generating data of the LSAPblockchain network in accordance with an embodiment.

The user interface 1700 shows a view of the log book which includesviews of service bulleting id 1710, the compliance data/hours 1720, themodule in compliance with 1730, any remarks 1740, who entered theremarks 1750 and the who signed 1760 the software update (i.e. whovalidated the software update).

FIG. 18 is a network diagram 1800 of the blockchain ledger with thecommunication network aircraft related to the orchestrated activitiesfor generating data of the LSAP blockchain network in accordance with anembodiment.

The network diagram 1800 includes the server system 1808 which, ininstances, may include several server farms having blockchain ledgers1815 enabling access of the data by multiple parties. The aircraft 1806in communication via a data communication network 1810 with the serversystem 1808, the operator maintenance office 1812 and a computing device1802 providing client access.

The computing device 1802 may be implemented by any computing devicethat includes at least one processor, some form of memory hardware, auser interface, and communication hardware. For example, the computingdevice 1802 may be implemented using a personal computing device, suchas a tablet computer, a laptop computer, a personal digital assistant(PDA), a smartphone, or the like. In this scenario, the computing device1802 is capable of storing, maintaining, and executing an blockchainnetwork applications associated with activities of clients andorganizations for loading LSAP software updates with the aircraft 1806systems.

The aircraft 1806 may be any aviation vehicle for which LSAP updates areapplicable in response to service notice bulletins. The aircraft 1806may be implemented as an airplane, helicopter, spacecraft, hovercraft,unmanned air vehicle, or the like. The one or more avionics systems 1804may include any system capable of receiving software updates via thecommunication systems of the aircraft.

The server system 1808 may include any number of application servers,and each server may be implemented using any suitable computer. In someembodiments, the server system 1808 includes one or more dedicatedcomputers. In some embodiments, the server system 1808 includes one ormore computers carrying out other functionality in addition to serveroperations. The server system 1808 may store and provide any type ofexecutable applications and data that is compatible with the computingdevice 1802 and is related to the updating of software updates asrequired by service bulletins for maintenance service of an aircraft. Inaddition, the server system 1808 may store rules, procedures, requestsetc. . . . associated with entities of various nodes in the blockchainnetwork for managing clients at the computing device 1802.

The computing device 1802 is usually located with the maintenancetechnician or onboard the aircraft 1806, and the computing device 1802communicates with the one or more avionics systems on the aircraft 1806via wired and/or wireless communication connection. The computing device1802 and the server system 1808 are generally disparately located, andthe computing device 1802 communicates with the server system 1808 viathe data communication network 1810 and/or via communication mechanismsonboard the aircraft 1806.

The data communication network 1810 may be any digital or othercommunications network capable of transmitting messages or data betweendevices, systems, or components. In certain embodiments, the datacommunication network 1810 includes a packet switched network thatfacilitates packet-based data communication, addressing, and datarouting. The packet switched network could be, for example, a wide areanetwork, the Internet, or the like. In various embodiments, the datacommunication network 1810 includes any number of public or private dataconnections, links or network connections supporting any number ofcommunications protocols. The data communication network 1810 mayinclude the Internet, for example, or any other network based uponTCP/IP or other conventional protocols. In various embodiments, the datacommunication network 1810 could also incorporate a wireless and/orwired telephone network, such as a cellular communications network forcommunicating with mobile phones, personal digital assistants, and/orthe like. The data communication network 1810 may also incorporate anysort of wireless or wired local and/or personal area networks, such asone or more IEEE 802.3, IEEE 802.16, and/or IEEE 802.11 networks, and/ornetworks that implement a short range (e.g., Bluetooth) protocol. Forthe sake of brevity, conventional techniques related to datatransmission, signaling, network control, and other functional aspectsof the systems (and the individual operating components of the systems)may not be described in detail herein.

FIG. 19 is a functional block diagram of a computing device related tothe orchestrated activities for generating data of the LSAP blockchainnetwork in accordance with an embodiment. It should be noted that thecomputing device 1900 can be implemented with the computing device 1802depicted in FIG. 18. In this regard, the computing device 1900 showscertain elements and components of the computing device 1802 in moredetail.

The computing device 1900 generally includes, without limitation: atleast one processor 1902; system memory 1904; a user interface 1906; acommunication interface device 1908; LSAP loading module 1912; ablockchain ledger module 1914 and a display device 1916. These elementsand features of the computing device 1900 may be operatively associatedwith one another, coupled to one another, or otherwise configured tocooperate with one another as needed to support the desiredfunctionality—in particular, the distributed ledger is used to obtainthe digital service record into a first block of the blockchain ledgerin the blockchain ledger module 1914 and to initiate at least oneloading and installing activity performed upon the software embedded inthe aircraft to effect updating using the distributable software codeand to insert into the distributed ledger of the blockchain ledgermodule 1914 of a second block of the blockchain storing a record ofloading and installing activity by the LSAP loading module 1912 isperformed.

For ease of illustration and clarity, the various physical, electrical,and logical couplings and interconnections for these elements andfeatures are not depicted in FIG. 19. Moreover, it should be appreciatedthat embodiments of the computing device 1900 will include otherelements, modules, and features that cooperate to support the desiredfunctionality. For simplicity, FIG. 19 only depicts certain elementsthat relate to the techniques described in more detail below.

The at least one processor 1902 may be implemented or performed with oneor more general purpose processors, a content addressable memory, adigital signal processor, an application specific integrated circuit, afield programmable gate array, any suitable programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination designed to perform the functions described here. Inparticular, the at least one processor 1902 may be realized as one ormore microprocessors, controllers, microcontrollers, or state machines.Moreover, the at least one processor 1902 may be implemented as acombination of computing devices, e.g., a combination of digital signalprocessors and microprocessors, a plurality of microprocessors, one ormore microprocessors in conjunction with a digital signal processorcore, or any other such configuration.

The at least one processor 1902 is communicatively coupled to the systemmemory 1904. The system memory 1904 is configured to store any obtainedor generated data associated with blockchain ledger of the blockchainledger module 1914. The system memory 1904 may be realized using anynumber of devices, components, or modules, as appropriate to theembodiment. Moreover, the computing device 1900 could include systemmemory 1904 integrated therein and/or a system memory 1904 operativelycoupled thereto, as appropriate to the particular embodiment. Inpractice, the system memory 1904 could be realized as RAM memory, flashmemory, EPROM memory, EEPROM memory, registers, a hard disk, a removabledisk, or any other form of storage medium known in the art.

The user interface 1906 may include or cooperate with various featuresto allow a user to interact with the computing device 1900. Accordingly,the user interface 1906 may include various human-to-machine interfaces,e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad,a joystick, a pointing device, a virtual writing tablet, a touch screen,a microphone, or any device, component, or function that enables theuser to select options, input information, or otherwise control theoperation of the computing device 1900.

In certain embodiments, the user interface 1906 may include or cooperatewith various features to allow a user to interact with the computingdevice 1900 via graphical elements rendered on a display element (e.g.,the display device 1916). Accordingly, the user interface 1906 mayinitiate the creation, maintenance, and presentation of a graphical userinterface (GUI). In certain embodiments, the display device 1916implements touch-sensitive technology for purposes of interacting withthe GUI. Thus, a user can manipulate the GUI by moving a cursor symbolrendered on the display device 1916, or by physically interacting withthe display device 1916 itself for recognition and interpretation, viathe user interface 1906.

The communication interface device 1908 is suitably configured tocommunicate data between the computing device 1900 and one or moreremote servers and one or more avionics systems onboard an aircraft. Thecommunication interface device 1908 may transmit and receivecommunications over a wireless local area network (WLAN), the Internet,a satellite uplink/downlink, a cellular network, a broadband network, awide area network, or the like. As described in more detail below, datareceived by the communication interface device 1908 may include, withoutlimitation: data of the orchestrated activities by maintenancetechnician from issued service bulletins in clients per the rules formedby trusted workflow contracts of entities associated with nodes inservers in the blockchain network.

In various exemplary embodiments, each of the tasks is initiated by anautomated agent/manual process in the network as transactions. Thetransactions associated with each task are verified by the contractrules which are in turn endorsing or validated by nodes in the network.Upon endorsement, each tasks or sets of task configures a block which isrecorded as an immutable record in the body of the block of the blockchain. An automated tamper proof records generation results in whichevery transaction in the network is recorded in the distributed ledgerof the block chain. The ledger resides as the official maintenancerecord for a particular aircraft. The application software of any nodein the network may depending on rights given enable a viewing of therecords. In an exemplary embodiment, an inspector the FAA can perform aremote audit of the maintenance records by accessing the blockchainledger associated with the particular aircraft without visiting themaintenance facility, and without having to inspect the aircraft inperson to validate the accuracy of the record in the ledger.

Techniques and technologies may be described herein in terms offunctional and/or logical block components, and with reference tosymbolic representations of operations, processing tasks, and functionsthat may be performed by various computing components or devices. Suchoperations, tasks, and functions are sometimes referred to as beingcomputer-executed, computerized, software-implemented, orcomputer-implemented. In practice, one or more processor devices cancarry out the described operations, tasks, and functions by manipulatingelectrical signals representing data bits at memory locations in thesystem memory, as well as other processing of signals. The memorylocations where data bits are maintained are physical locations thathave particular electrical, magnetic, optical, or organic propertiescorresponding to the data bits. It should be appreciated that thevarious block components shown in the figures may be realized by anynumber of hardware, software, and/or firmware components configured toperform the specified functions. For example, an embodiment of a systemor a component may employ various integrated circuit components, e.g.,memory elements, digital signal processing elements, logic elements,look-up tables, or the like, which may carry out a variety of functionsunder the control of one or more microprocessors or other controldevices.

When implemented in software or firmware, various elements of thesystems described herein are essentially the code segments orinstructions that perform the various tasks. The program or codesegments can be stored in a processor-readable medium or transmitted bya computer data signal embodied in a carrier wave over a transmissionmedium or communication path. The “computer-readable medium”,“processor-readable medium”, or “machine-readable medium” may includeany medium that can store or transfer information. Examples of theprocessor-readable medium include an electronic circuit, a semiconductormemory device, a ROM, a flash memory, an erasable ROM (EROM), a floppydiskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium,a radio frequency (RF) link, or the like. The computer data signal mayinclude any signal that can propagate over a transmission medium such aselectronic network channels, optical fibers, air, electromagnetic paths,or RF links. The code segments may be downloaded via computer networkssuch as the Internet, an intranet, a LAN, or the like.

The following description refers to elements or nodes or features being“connected” or “coupled” together. As used herein, unless expresslystated otherwise, “coupled” means that one element/node/feature isdirectly or indirectly joined to (or directly or indirectly communicateswith) another element/node/feature, and not necessarily mechanically.Likewise, unless expressly stated otherwise, “connected” means that oneelement/node/feature is directly joined to (or directly communicateswith) another element/node/feature, and not necessarily mechanically.Thus, although the schematic shown depicts one exemplary arrangement ofelements, additional intervening elements, devices, features, orcomponents may be present in an embodiment of the depicted subjectmatter.

For the sake of brevity, conventional techniques related to signalprocessing, data transmission, signaling, network control, and otherfunctional aspects of the systems (and the individual operatingcomponents of the systems) may not be described in detail herein.Furthermore, the connecting lines shown in the various figures containedherein are intended to represent exemplary functional relationshipsand/or physical couplings between the various elements. It should benoted that many alternative or additional functional relationships orphysical connections may be present in an embodiment of the subjectmatter.

Some of the functional units described in this specification have beenreferred to as “modules” in order to more particularly emphasize theirimplementation independence. For example, functionality referred toherein as a module may be implemented wholly, or partially, as ahardware circuit include custom VLSI circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A module may also be implemented in programmablehardware devices such as field programmable gate arrays, programmablearray logic, programmable logic devices, or the like. Modules may alsobe implemented in software for execution by various types of processors.An identified module of executable code may, for instance, include oneor more physical or logical modules of computer instructions that may,for instance, be organized as an object, procedure, or function.Nevertheless, the executables of an identified module need not bephysically located together, but may include disparate instructionsstored in different locations that, when joined logically together,include the module and achieve the stated purpose for the module.Indeed, a module of executable code may be a single instruction, or manyinstructions, and may even be distributed over several different codesegments, among different programs, and across several memory devices.Similarly, operational data may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application.

What is claimed is:
 1. A computer-implemented blockchain system forremotely distributing, updating and verifying the installation ofsoftware embedded in an aircraft and for creating a built-in blockchainrecord of distributing, updating and verifying activities as proofs,comprising: a data communication network having a plurality of nodeseach node implemented by at least one computer programmed tocooperatively maintain a copy of a distributed ledger organized as ablockchain of linked encrypted record-storing blocks; at least a firstone of said plurality of nodes being programmed to insert into thedistributed ledger in a first block of the blockchain storing, as anautomated workflow, a service record that contains (a) distributablesoftware code for updating the software embedded in the aircraft, andthat specifies (b) rules prescribing activities for loading andinstalling the software embedded in the aircraft, and (c) rules forverifying that the updated software conforms to a predefined orprescribed standard; at least a second one of said plurality of nodesbeing programmed (a) to access the distributed ledger to obtain theservice record and to initiate at least one loading and installingactivity performed upon the software embedded in the aircraft to effectupdating thereof using the distributable software code and (b) to insertinto the distributed ledger a second block of the blockchain storing arecord of a fact that the at least one loading and installing activitywas performed and the success thereof; at least a third one of saidplurality of nodes being programmed (a) to access the distributed ledgerto obtain the service record and to apply at least one verifying rule totest whether the updated software conforms to the predefined orprescribed standard and (b) to insert into the distributed ledger athird block of the blockchain storing a service record of the fact thatthe at least one verifying rule was applied and an outcome thereof; andat least the first, second and third ones of said plurality of nodesbeing programmed to collectively share immutable copies of the first,second and third blocks of the blockchain thereby ensuring that thedistributed ledger is immutable.
 2. The computer-implemented blockchainsystem of claim 1, wherein the first, second and third nodes togethercontrol the installation of the software embedded in the aircraft in amanner to ensure no inadvertent activities are performed.
 3. Thecomputer-implemented blockchain system of claim 2, wherein theinstallation by the first, second and third nodes is controlled by atrusted workflow contract executed by an entity associated with at leastone of the first, second or third nodes.
 4. The computer-implementedblockchain system of claim 3, wherein the trusted workflow contractcomprises: a set of rules for updating the software to: assessapplicability of the software update for a particular aircraft; validatewhether the software update is correctly loaded into the particularaircraft; and verify whether at a post load completion of the softwareupdate, the software complies with an approved software update loadingprocedure.
 5. The computer-implemented blockchain system of claim 4,wherein the nodes are a plurality of entities comprising: a loadablesoftware airplane part (LSAP) supplier, a carrier, a regulator, owner,and an aircraft.
 6. The computer-implemented blockchain system of claim1, further comprising: at least one activity of a plurality ofactivities stored in the record of the second block of actions performedby a plurality of clients in a pipeline processing defined by theapproved software update loading procedure and associated with theplurality of nodes wherein the plurality of activities performedcomprise one or more steps of: publishing a service bulletin, monitoringa fleet of aircrafts, creating a work order, monitoring a softwareupdate loading process, selecting and uploading a software update,verifying a software update, checking a compliance and viewing alogbook.
 7. The computer-implemented blockchain system of claim 6,wherein the plurality of clients comprise one or more clients of:software part supplier, maintenance manager, maintenance technician,inspector, and a pilot.
 8. The computer-implemented blockchain system ofclaim 7, wherein the one or more clients associated with the activitiesare remotely located from the entities associated with the nodes.
 9. Amethod for remotely distributing, updating and verifying softwareupdates in an aircraft and for creating a built-in blockchain record ofdistributing, updating and verifying activities as proofs, the methodcomprising: configuring a data communication network having a pluralityof nodes each node implemented by at least one computer programmed tocooperatively maintain a copy of a distributed ledger organized as ablockchain of linked encrypted record-storing blocks; programming atleast a first one of said plurality of nodes to insert into thedistributed ledger in a first block of the blockchain storing, as anautomated workflow, a service record that contains (a) distributablesoftware code for updating the software embedded in the vehicle, andthat specifies (b) rules prescribing activities for loading andinstalling the software embedded in the aircraft, and (c) rules forverifying that the updated software conforms to a predefined orprescribed standard; programming at least a second one of said pluralityof nodes (a) to access the distributed ledger to obtain the servicerecord and to initiate at least one loading and installing activityperformed upon the software embedded in the aircraft to effect updatingthereof using the distributable software code and (b) to insert into thedistributed ledger a second block of the blockchain storing a servicerecord of the fact that the at least one loading and installing activitywas performed and the success thereof; programming at least a third oneof said plurality of nodes (a) to access the distributed ledger toobtain the service record and to apply at least one verifying rule totest whether the updated software conforms to the predefined orprescribed standard and (b) to insert into the distributed ledger athird block of the blockchain storing a service record of a fact thatthe at least one verifying rule was applied and an outcome thereof; andprogramming at least the first, second and third ones of said pluralityto collectively share immutable copies of the first, second and thirdblocks of the blockchain thereby ensuring that the distributed ledger isimmutable.
 10. The method of claim 9 wherein the first, second and thirdnodes together control the installation of the software embedded in theaircraft in a manner to ensure no inadvertent activities are performed.11. The method of claim 10, wherein the installation by the first,second and third nodes is controlled by a trusted workflow contractexecuted by an entity associated with at least one of the first, secondor third nodes.
 12. The method of claim 11, wherein the trusted workflowcontract comprises: a set of rules for updating the software for:assessing applicability of the software update for a particularaircraft; validating whether the software update is correctly loadedinto the particular aircraft; and verifying whether at a post loadcompletion of the software update, the software complies with anapproved software update loading procedure.
 13. The method of claim 12,wherein the nodes are a plurality of entities comprising: a loadablesoftware airplane part (LSAP) supplier, a carrier, a regulator, owner,and an aircraft.
 14. The method of claim 13, further comprising: storingat least one activity of a plurality of activities in the second blockservice record of actions performed by a plurality of clients in apipeline processing defined by the approved software update loadingprocedure and associated with the plurality of nodes wherein theplurality of activities performed comprise one or more steps of:publishing a service bulletin, monitoring a fleet of aircrafts, creatinga work order, monitoring a software update loading process, selectingand uploading a software update, verifying a software update, checking acompliance and viewing a logbook.
 15. The method of claim 14, whereinthe plurality of clients comprise one or more clients of: software partsupplier, maintenance manager, maintenance technician, inspector, and apilot.
 16. The method of claim 15, wherein the one or more clientsassociated with the activities are remotely located from the entitiesassociated with the nodes.
 17. A method for executing instructions on anon-transitory computer-readable medium by at least one processor, themethod comprising: configuring a data communication network having aplurality of nodes each node implemented by the at least one processorprogrammed to cooperatively maintain a copy of a distributed ledgerorganized as a blockchain of linked encrypted record-storing blocks;programming at least a first one processor of said plurality of nodes toinsert into the distributed ledger in a first block of the blockchainstoring, as an automated workflow, a service record that contains (a)distributable software code for updating the software embedded in anaircraft, and that specifies (b) rules prescribing activities forloading and installing the software embedded in the aircraft, and (c)rules for verifying that the updated software conforms to a predefinedor prescribed standard; programming at least a second one processor ofsaid plurality of nodes (a) to access the distributed ledger to obtainthe service record and to initiate at least one loading and installingactivity performed upon the software embedded in the aircraft to effectupdating thereof using the distributable software code and (b) to insertinto the distributed ledger a second block of the blockchain storing aservice record of a fact that the at least one loading and installingactivity was performed and the success thereof; programming at least athird one processor of said plurality of nodes (a) to access thedistributed ledger to obtain the service record and to apply at leastone verifying rule to test whether the updated software conforms to thepredefined or prescribed standard and (b) to insert into the distributedledger a third block of the blockchain storing a service record of afact that the at least one verifying rule was applied and an outcomethereof; and programming at least the first, second and third oneprocessors of said plurality of nodes to collectively share immutablecopies of the first, second and third blocks of the blockchain therebyensuring that the distributed ledger is immutable.
 18. The method ofclaim 17, wherein the first, second and third one processors of saidplurality of nodes together control the installation of the softwareembedded in the aircraft in a manner to ensure no inadvertent activitiesare performed wherein the installation is controlled by a trustedworkflow contract executed by an entity associated with at least one ofthe first, second or third nodes.
 19. The method of claim 18, whereinthe trusted workflow contract comprises: a set of rules for updating thesoftware for: assessing applicability of the software update for aparticular aircraft; validating whether the software update is correctlyloaded into the particular aircraft; and verifying whether at a postload completion of the software update, the software complies with anapproved software update loading procedure.
 20. The method of claim 19,further comprising: storing at least one activity of a plurality ofactivities in the second block service record of actions performed by aplurality of clients in a pipeline processing defined by the approvedsoftware update loading procedure and associated with the plurality ofnodes wherein the plurality of activities performed comprise one or moresteps of: publishing a service bulletin, monitoring a fleet ofaircrafts, creating a work order, monitoring a software update loadingprocess, selecting and uploading a software update, verifying a softwareupdate, checking a compliance and viewing a logbook.